Understood, ich bin dran, Sie werden彝.

Die Anmerkungen haben wir schon auf der Webseite geschrieben.

Damit soll es mal weitergehen.

Ihr habt ja alle eure Aufgaben, die ihr programmiert habt, abgegeben.

Das fand ich soweit durchgehend gut.

Es war kein Problem. Ein paar Anmerkungen habe ich euch zurückgeschrieben.

Man kann es vielleicht noch ein bisschen vereinfacht hinschreiben.

Aber von der Idee her war es bei allen sehr schön.

Die nächste Aufgabe wäre dann, Interrupts einzubauen in die virtuellen Maschinen, die ihr bisher gebastelt habt.

Da mal ein bisschen angucken, wie schaut das mit Interrupts aus?

Aus Betriebssystems Sicht sagt man immer, Interrupt, irgendein Gerät will etwas von der CPU.

Ich zippe eine Taste, Tastaturkontroller merkt, die Taste ist gedrückt und sagt dem Betriebssystem, CPU, da ist etwas. Mach mal.

Der CPU kann dann darauf reagieren und das Zeichen vom Tastaturkontroller abholen.

Warum macht man das? Weil man aktives Warten vermeiden will. Ihr kennt das alle.

Ich möchte nicht den Tastaturkontroller alle Millisekunde mal fragen. Hast du was? Hast du nichts? Na gut, mach ich weiter.

Hast du immer noch nichts? Na gut, mach ich weiter.

Was so ähnlich aussieht, sind Exceptions.

Wasch nennt es immer Trebs. Wie auch immer man die Dinger nennen möchte.

Exceptions, Trebs, System Calls, das ist so, jeder nennt es ein bisschen anders.

Was soll das sein? Also was meine ich jetzt damit? Also ich trenne es immer auf Interrupts und Exception.

Interrupts sind Events, die von außen signalisiert werden.

Exception sind Events, die die CPU sich selber sendet.

So nach dem Motto, äh, bei der Division ist was schief gelaufen.

Oder beim Speicherzugriff, das funktioniert so nicht.

Dann signalisiert die CPU sich selber, dass sie sich um irgendwas kümmern soll.

Also wie die Fehlerbehandlung dann aussieht, muss man sich dann halt entsprechend programmieren.

Das letzte System Calls oder Trebs, oder wie auch immer man die Dinger nennen mag.

Da geht es letztendlich darum, dass die CPU normalerweise dann von dem User Modus in den Kernel Modus wechselt.

Das ist ein wesentlicher Punkt, der Rest ist eigentlich, ja, braucht man eigentlich nicht.

Es ist nur, muss man halt irgendwie machen, dass die CPU dann aus dem User Land in den Betriebssystemen Kern kommt.

So, wofür hat man das? Gut, normalerweise geschieht das im Sinne von rechter Verwaltung.

Nicht jeder soll auch Platte schreiben, nicht jeder soll von Platte lesen.

Also muss ich im User Programm in das Betriebssystem wechseln und im privilegierten Modus, da kann ich dann Platte lesen schreiben.

Zum Beispiel.

Interrupt, ihr kennt das alle, sind asynchron. CPU weiß nichts von.

Weiß nicht wann die kommen.

Quelle dementsprechend extern, nicht vorhersagbar, normalerweise nicht wiederholbar.

Was natürlich ein bisschen blöd ist im Sinne von Testen.

Ihr kennt das alle, ihr könnt tausendmal eine Taste tippen, alles funktioniert wunderbar.

Und beim tausenden ersten Mal kommt der Interrupt zur falschen Sekunde und, oh, Maschine steht vor, oder so was.

Ja, im Sinne von virtuelle Maschine ist das natürlich, aber möglicherweise doch wiederholbar.

Da wird es eine Maschine, die könnte dann natürlich die Zyklen zählen und nach dem 10.043.000 Zyklus signalisiert er den Interrupt,

dann kommt er immer zum gleichen Zeitpunkt. Manchmal ganz neckisch zum Testen von Betriebssystemen.

Ja, aus Sicht eines laufenden Prozesses sind die Interrupts transparent.

Also der Interrupt sollte kommen, CPU wechselt ins Betriebssystem, Betriebssystem holt sich ein Tastaturbite ab,

speichert das in irgendeinem Puffer und kehrt aus dem Interrupt zurück, Userprogramm läuft weiter und weiß von nichts.

So die Idee.

Wie schaut denn das aus, oder erkennt ihr da ein Gegenbeispiel?

Das Userprogramm, doch eine Unterbrechung bemerkt.

Wie schaut es mit Ctrl C aus? Also merken ist so viel gesagt, merkt es nix mehr, aber wie ist denn das gemacht?